WEBVTT Kind: captions; Language: en 00:00:12.000 --> 00:00:14.001 Hi, I'm Paul KB5MU. 00:00:15.000 --> 00:00:18.000 I'm here to propose a method for user authentic 00:01:12.001 --> 00:01:14.001 [...] amateur satellites. 00:01:16.001 --> 00:01:22.000 Amateur radio has been using satellites since late 1961, and the technology 00:01:22.000 --> 00:01:23.001 has been constantly evolving. 00:01:25.000 --> 00:01:28.000 Except for the recent profusion of single channel FM 00:01:28.000 --> 00:01:29.001 satellites, the trend has been changing over the years. 00:01:34.000 --> 00:01:40.001 The next big step forward is to replace the linear transponders with high 00:01:40.001 --> 00:01:43.000 performance digital payloads. 00:01:43.001 --> 00:01:47.001 Open Research Institute has been working on a design for a digital satellite 00:01:47.001 --> 00:01:53.001 communication system called P4XT that uses many individual digital uplink 00:01:53.001 --> 00:01:59.001 channels in the 5GHz microwave band, an onboard multiplexer, and a single 00:01:59.001 --> 00:02:06.000 broadband DBBS2 or S2X digital downlink in the 10GHz microwave band. 00:02:06.001 --> 00:02:12.000 It will support many simultaneous real-time voice users, as well as a range of 00:02:12.000 --> 00:02:15.000 capabilities for both higher and lower bandwidth communications. 00:02:16.000 --> 00:02:20.001 The system is designed for a geostationary orbit, or for a high elliptical orbit. 00:02:21.000 --> 00:02:24.001 It can also be used terrestrially with a central station or ground sat 00:02:24.001 --> 00:02:26.000 in a prime location. 00:02:27.000 --> 00:02:32.001 It's our hope that this system will be affordable, easy to use, and very useful 00:02:32.001 --> 00:02:34.001 for actual communication between amateurs. 00:02:36.000 --> 00:02:40.000 Those characteristics will make the system popular with users, supporting a 00:02:40.000 --> 00:02:42.000 vibrant community of cooperating users. 00:02:43.001 --> 00:02:47.001 Unfortunately, a system like that may also attract various kinds of misbehavior. 00:02:48.001 --> 00:02:53.000 It might attract non-amateur users who wish to exploit the utility of the system. 00:02:54.000 --> 00:02:58.001 It might attract amateur users who disregard the rules and regulations and 00:02:58.001 --> 00:03:01.001 operating practices recommended by the satellite owner or operator. 00:03:03.000 --> 00:03:08.001 It might attract users with personal grudges against others who might seek to use 00:03:08.001 --> 00:03:11.001 the system for harassment or to deny use of the system to certain 00:03:11.001 --> 00:03:14.000 people, and so on. 00:03:14.001 --> 00:03:19.000 These types of misbehavior make the system less pleasant for the majority of 00:03:19.000 --> 00:03:24.000 cooperating users and can damage the reputation of the system and of the amateur 00:03:24.000 --> 00:03:26.000 radio and amateur satellite services as a whole. 00:03:27.001 --> 00:03:29.000 These risks are not imaginary. 00:03:30.000 --> 00:03:33.001 The amateur satellite service hasn't yet flown a system that was useful enough 00:03:33.001 --> 00:03:39.001 and easy enough to attract widespread pirate usage, but the US Navy FleetSat-com 00:03:39.001 --> 00:03:45.001 satellites from the late 1970s and 1980s have seen extensive pirate use. 00:03:45.001 --> 00:03:51.000 It was possible to buy the components of a pirate FleetSat-com terminal at any 00:03:51.000 --> 00:03:54.001 truck stop in Brazil, and non-military communications 00:03:54.001 --> 00:03:56.000 could often be hard on the downlink. 00:03:57.000 --> 00:04:01.001 Because the system was a bent pipe analog transponder, there was little the Navy 00:04:01.001 --> 00:04:05.001 could do about pirate users operating outside US jurisdiction. 00:04:07.000 --> 00:04:11.001 For examples of smaller scale abuse by individual users, we need only look to 00:04:11.001 --> 00:04:14.001 decades of experience with terrestrial FM repeaters. 00:04:15.000 --> 00:04:20.000 Most have well-behaved user communities, and the occasional misbehavior is 00:04:20.000 --> 00:04:23.001 readily discouraged by peer pressure or by merely ignoring it. 00:04:24.000 --> 00:04:28.000 But notoriously, there are other repeaters where misbehavior is quite 00:04:28.000 --> 00:04:29.001 common and out of control. 00:04:30.001 --> 00:04:34.000 The repeater owner's only recourse is to turn the system off. 00:04:35.000 --> 00:04:38.001 We also see misbehavior on HF bands, which can't be turned off. 00:04:39.001 --> 00:04:42.001 There's just no way to ban persistent abusers. 00:04:44.000 --> 00:04:48.000 Once we move to a fully digital system, though, it becomes possible to do better. 00:04:49.000 --> 00:04:53.001 If we are able to identify the origin of every transmission, then misbehaving 00:04:53.001 --> 00:04:55.000 operators can be held accountable. 00:04:56.001 --> 00:04:59.000 Just knowing that their identities are public might be 00:04:59.000 --> 00:05:00.001 enough to discourage most of them. 00:05:01.001 --> 00:05:06.001 If they persist in misbehaving, the system can deny them access, which eliminates 00:05:06.001 --> 00:05:09.001 most of their ability to damage the system and the community. 00:05:10.001 --> 00:05:13.001 Ignoring the thousands of other things that can go wrong with a satellite 00:05:13.001 --> 00:05:18.001 communication system – space is hard – we will concentrate on problems that can 00:05:18.001 --> 00:05:20.001 be caused by radio signals on the uplink. 00:05:22.000 --> 00:05:24.001 We can divide these up into two overlapping classes. 00:05:25.000 --> 00:05:27.000 Let's call them jammers and abusers. 00:05:28.000 --> 00:05:33.000 A jammer transmits an especially strong signal, with the intent of preventing the 00:05:33.000 --> 00:05:34.001 desired signals from being received. 00:05:35.000 --> 00:05:40.000 An abuser, on the other hand, transmits a signal that resembles a desired signal, 00:05:40.001 --> 00:05:43.000 with the intention of using the system in a way 00:05:43.000 --> 00:05:44.001 not intended by the satellite owner. 00:05:46.001 --> 00:05:51.000 A pure jammer is a brute force attack, aimed at denial of service. 00:05:52.000 --> 00:05:56.000 There are tricks that can help defend against such attacks, but with enough 00:05:56.000 --> 00:05:58.001 power, the jammer can always defeat the receiver, 00:05:59.000 --> 00:06:00.001 no matter how cleverly designed. 00:06:01.001 --> 00:06:04.001 All radio communication systems have this fundamental vulnerability. 00:06:05.001 --> 00:06:08.000 A strong enough jammer can prevent communications from working. 00:06:09.000 --> 00:06:14.000 On the plus side, that strong jammer is pretty easy to detect and locate, so it 00:06:14.000 --> 00:06:16.000 can eventually be forced to shut down. 00:06:17.001 --> 00:06:21.000 Even better, there's usually no big incentive to simply jam a whole communication 00:06:21.000 --> 00:06:24.001 system, unless it's of military or political importance. 00:06:25.001 --> 00:06:27.001 We can't prevent a jamming attack. 00:06:27.001 --> 00:06:32.000 We can't expect that such attacks on our amateur satellite system will be 00:06:32.000 --> 00:06:35.000 infrequent, short in duration, limited in 00:06:35.000 --> 00:06:38.000 effectiveness, and risky for the jammer. 00:06:39.000 --> 00:06:40.001 At least, we have to hope so. 00:06:43.001 --> 00:06:45.000 Abuse attacks are another matter. 00:06:45.001 --> 00:06:50.000 The abusing station is technically very similar to an ordinary user station, at 00:06:50.000 --> 00:06:53.001 least in terms of basic performance, antenna size, power amplifier, and so on. 00:06:54.001 --> 00:06:59.000 We want user stations to be affordable, available, and easy to use, which means 00:06:59.000 --> 00:07:02.000 that the potential abusers also have ready access to the equipment. 00:07:03.000 --> 00:07:07.001 The potential abuser doesn't need to emit any particularly loud signals, so it 00:07:07.001 --> 00:07:10.000 can hide among all the ordinary users and evade detection. 00:07:11.001 --> 00:07:16.000 Perhaps worst of all, in some cases there can be a strong incentive to abuse the 00:07:16.000 --> 00:07:20.001 system, as in the case of that Navy FleetSat-COM system I described earlier. 00:07:22.000 --> 00:07:27.000 We have not seen this kind of large-scale abuse on amateur satellites so far, 00:07:27.001 --> 00:07:30.001 probably because our systems have not reached the threshold of usefulness 00:07:30.001 --> 00:07:32.000 to attract pirate users. 00:07:33.000 --> 00:07:35.001 Maybe a P4 XT system will cross that threshold. 00:07:37.000 --> 00:07:41.000 What we have already seen on a large scale is accidental intruders interfering 00:07:41.000 --> 00:07:43.000 with satellite uplink frequencies. 00:07:43.001 --> 00:07:49.000 For example, on Oscar 13's Mode B linear transponder, it was pretty common to 00:07:49.000 --> 00:07:51.001 hear taxi dispatch traffic from Central America. 00:07:52.001 --> 00:07:55.000 Nothing could be done to reduce this clutter on the downlink. 00:07:57.000 --> 00:08:01.000 Any kind of regenerating digital transponder solves that problem right away. 00:08:01.001 --> 00:08:04.001 If a signal doesn't match the kind of signal the satellite is intended to 00:08:04.001 --> 00:08:09.000 receive, it gets filtered out and cannot accidentally appear on the downlink. 00:08:10.001 --> 00:08:12.001 So we have narrowed down the problem quite a bit. 00:08:13.000 --> 00:08:16.001 The only ground stations that can really disrupt the orderly operation of the 00:08:16.001 --> 00:08:21.000 system short of brute force jamming are stations that accurately mimic the 00:08:21.000 --> 00:08:23.000 characteristics of a normal user uplink. 00:08:24.000 --> 00:08:28.000 This is similar to the situation we have today on terrestrial FM repeaters. 00:08:29.000 --> 00:08:34.001 What we need is a way to unambiguously identify the source of any transmission. 00:08:36.000 --> 00:08:41.001 On digital voice systems based on LAN mobile technologies like DSTAR or DMR, each 00:08:41.001 --> 00:08:46.000 station is configured to transmit identification automatically, and unidentified 00:08:46.000 --> 00:08:47.001 transmissions are invalid. 00:08:49.000 --> 00:08:51.001 But there's nothing stopping an abuser from entering a false identity. 00:08:52.001 --> 00:08:56.001 We need to add a way to definitely tie each use of a call sign 00:08:56.001 --> 00:08:58.001 to its actual licensee. 00:08:59.001 --> 00:09:03.001 This problem is very similar to well-known security issues that arise on the 00:09:03.001 --> 00:09:07.000 internet, and standard cryptographically secure techniques exist 00:09:07.000 --> 00:09:09.000 that can be used to solve it. 00:09:10.000 --> 00:09:15.000 We propose a specific system designed for authentication of users on the uplink 00:09:15.000 --> 00:09:17.001 to the P4XT digital transponder. 00:09:19.001 --> 00:09:23.000 The design of this system is constrained by the rules and regulations 00:09:23.000 --> 00:09:24.001 in the Amateur Satellite Service. 00:09:26.000 --> 00:09:29.001 Under the United States rules enforced by the Federal Communications Commission, 00:09:30.000 --> 00:09:36.001 the FCC, no amateur station shall transmit messages encoded for the purpose 00:09:36.001 --> 00:09:40.001 of obscuring their meaning, except as otherwise provided herein. 00:09:42.000 --> 00:09:45.001 That is to say, we're not allowed to encrypt the contents of our messages. 00:09:46.001 --> 00:09:50.000 There is nothing in the FCC rules that prohibits the use of cryptographic 00:09:50.000 --> 00:09:54.001 techniques for other purposes, such as authenticating amateur uplinks. 00:09:55.000 --> 00:09:58.000 We just have to be careful not to encrypt any message data. 00:09:59.000 --> 00:10:01.000 Other countries have similar rules. 00:10:02.000 --> 00:10:04.001 Some countries may have much stricter rules. 00:10:05.000 --> 00:10:08.001 It may not be legal to use the proposed system in such countries without a 00:10:08.001 --> 00:10:10.000 special waiver or rules change. 00:10:12.000 --> 00:10:16.000 The design is further constrained by the need to be fairly efficient in terms 00:10:16.000 --> 00:10:17.001 of uplink resources used. 00:10:18.000 --> 00:10:23.000 We will need to add some authentication data to every uplink transmission, but 00:10:23.000 --> 00:10:26.000 that overhead needs to be kept pretty small in order to avoid 00:10:26.000 --> 00:10:27.001 wasting too much uplink bandwidth. 00:10:28.001 --> 00:10:32.000 It turns out we will also need to occasionally perform an exchange of larger 00:10:32.000 --> 00:10:35.000 authentication messages between the ground station and the satellite. 00:10:36.000 --> 00:10:39.000 Those transactions can't occur too often, again, because of efficiency. 00:10:40.000 --> 00:10:44.001 The rate at which the authentication transactions take place needs to be under 00:10:44.001 --> 00:10:48.001 the control of the satellite, since the satellite has to handle a large number of 00:10:48.001 --> 00:10:52.000 simultaneous users and has limited onboard resources 00:10:52.000 --> 00:10:53.001 for storage and for computation. 00:10:56.000 --> 00:11:02.000 And we assume, for the purposes of this design, that policy decisions governing 00:11:02.000 --> 00:11:06.001 uplink authentication are made by the entity that owns or operates the satellite. 00:11:08.000 --> 00:11:11.001 We hope that most systems can normally be operated in a very relaxed 00:11:11.001 --> 00:11:15.001 authentication mode, with any licensed amateur radio operator welcome 00:11:15.001 --> 00:11:17.000 to use the system at any time. 00:11:18.000 --> 00:11:22.001 We acknowledge that there may be periods of time, such as communications drills 00:11:22.001 --> 00:11:28.000 or emergencies, when it is desirable to limit the use of a satellite to a 00:11:28.000 --> 00:11:30.000 predetermined list of users. 00:11:31.000 --> 00:11:35.000 We have also designed the system to handle the case where the owner maintains a 00:11:35.000 --> 00:11:38.001 block list of stations that are not currently permitted to use the system. 00:11:39.001 --> 00:11:43.000 We leave the policy procedures up to the satellite owner to define. 00:11:43.000 --> 00:11:47.001 We just provide the mechanisms by which the users can be identified in real time, 00:11:48.000 --> 00:11:52.001 so that services can be provided or denied based on policy. 00:11:55.000 --> 00:11:59.001 Uplink transmissions on the P4 XT system are divided up into 40 millisecond 00:11:59.001 --> 00:12:03.000 frames, mainly because that's what works best for digital voice. 00:12:04.000 --> 00:12:08.000 Each time the ground station activates its transmitter, the first 40 millisecond 00:12:08.000 --> 00:12:12.001 frame is devoted to a fixed data pattern called a preamble, designed to be easy 00:12:12.001 --> 00:12:15.000 for the satellite to recognize and synchronize with. 00:12:15.001 --> 00:12:20.001 After that one preamble frame, every transmitted frame thereafter consists of a 00:12:20.001 --> 00:12:25.000 fixed synchronization word that marks the beginning of the frame, a short frame 00:12:25.000 --> 00:12:27.001 header, and a fixed number of payload bytes. 00:12:28.001 --> 00:12:33.001 The frame header contains the claimed identity of the ground station, which may 00:12:33.001 --> 00:12:40.000 be a plain callsign like KB5MU, or a decorated callsign such as KB5MU 00:12:40.000 --> 00:12:45.000 -15, or actually anything that fits into nine uppercase letters, 00:12:45.001 --> 00:12:47.000 digits, and a few punctuation marks. 00:12:48.001 --> 00:12:52.000 The header also contains other fields pertaining to the P4 XT uplink. 00:12:53.000 --> 00:12:57.001 The header is heavily encoded using a Golay code, so it's quite robust 00:12:57.001 --> 00:12:59.000 and usually received without errors. 00:13:00.000 --> 00:13:04.000 We extend the frame header by three bytes to make room for 00:13:04.000 --> 00:13:05.001 an authentication token. 00:13:07.000 --> 00:13:11.001 An authentication token is a meaningless number, not part of any message. 00:13:12.001 --> 00:13:16.001 The ground station creates the token and inserts it into the uplink frame header. 00:13:18.000 --> 00:13:22.000 When the satellite wishes to check the authenticity of the uplink, it extracts 00:13:22.000 --> 00:13:24.000 the token from the frame header and checks it. 00:13:24.001 --> 00:13:29.000 It's important that the ground station and the satellite can both compute the 00:13:29.000 --> 00:13:32.001 same token values, and that nobody else can do so. 00:13:33.001 --> 00:13:37.000 Anybody who is able to come up with a valid token value for another ground 00:13:37.000 --> 00:13:41.000 station will be able to impersonate that ground station, for however long 00:13:41.000 --> 00:13:42.001 that token value is valid. 00:13:43.001 --> 00:13:47.000 So we want the token to be valid for only a very short period of time, so that it 00:13:47.000 --> 00:13:50.001 would be impersonated or can't just intercept the token being transmitted on the 00:13:50.001 --> 00:13:52.001 uplink and reuse it. 00:13:54.000 --> 00:13:56.000 That would be the token value would change for every frame. 00:13:56.001 --> 00:14:00.001 So we need a method that allows the ground station to generate an endless stream 00:14:00.001 --> 00:14:02.001 of unpredictable, random looking numbers. 00:14:03.000 --> 00:14:06.000 And we need the satellite to be able to generate exactly the same stream of 00:14:06.000 --> 00:14:08.000 numbers, and we need it to be practically 00:14:08.000 --> 00:14:09.001 impossible for anyone else to do the same. 00:14:10.001 --> 00:14:13.001 We also need to be sure that the sequence of numbers never repeats. 00:14:15.000 --> 00:14:19.000 Okay, this is a familiar problem, and it's solved by a cryptographic protocol 00:14:19.000 --> 00:14:23.000 called Time-Based One-Time Password, or TOTP. 00:14:24.000 --> 00:14:28.001 This is the same thing used by apps like Google Authenticator, or by those little 00:14:28.001 --> 00:14:33.000 keychain gadgets that display a different six digit number every 30 seconds, used 00:14:33.000 --> 00:14:34.001 for two-factor authentication online. 00:14:36.000 --> 00:14:39.001 I'm not going to try to explain the math, but here's how it 00:14:39.001 --> 00:14:41.000 works at a block diagram level. 00:14:42.000 --> 00:14:44.001 We have a cryptographic computation called a hash function. 00:14:45.001 --> 00:14:50.000 A hash function takes some number of input bits, and generates a fixed number of 00:14:50.000 --> 00:14:53.000 output bits that depends only on the input bits. 00:14:54.000 --> 00:14:56.001 But in a complicated way that's practically impossible to reverse. 00:14:58.000 --> 00:15:01.000 There are standard accepted hash functions used for this kind of purpose, with 00:15:01.000 --> 00:15:03.001 names like SHA-1 and SHA-256. 00:15:05.001 --> 00:15:07.001 For input bits, we need at least two sources. 00:15:08.001 --> 00:15:10.000 One source is the date and time. 00:15:11.001 --> 00:15:14.000 The time changes with every frame, and time is always increasing, 00:15:14.001 --> 00:15:16.001 so we never get the same input twice. 00:15:17.001 --> 00:15:19.001 Time is, of course, well known to everybody. 00:15:20.000 --> 00:15:24.001 So we need an extra input, called a shared secret, which is known to the 00:15:24.001 --> 00:15:29.000 authentic ground station and to the satellite, but not known by anybody else. 00:15:31.000 --> 00:15:33.000 Where does this magical shared secret come from? 00:15:34.000 --> 00:15:36.000 It turns out this is also a standard problem. 00:15:36.001 --> 00:15:38.001 It may surprise you to learn that we can create this shared 00:15:38.001 --> 00:15:40.001 secret securely over the air. 00:15:42.000 --> 00:15:44.001 Among other advantages, this means we can replace 00:15:44.001 --> 00:15:46.001 the shared secret as often as we like. 00:15:48.000 --> 00:15:50.000 The standard methods for generating a shared 00:15:50.000 --> 00:15:51.001 secret are called key agreement protocols. 00:15:53.000 --> 00:15:57.000 The best known key agreement protocol is called Diffie-Hellman, after 00:15:57.000 --> 00:15:58.001 two of its brilliant inventors. 00:15:59.001 --> 00:16:03.000 If you're at all interested in cool math, and aren't familiar with Diffie 00:16:03.000 --> 00:16:04.001 -Hellman, you should go read up on it. 00:16:05.000 --> 00:16:06.001 I can't go into the math here. 00:16:07.001 --> 00:16:11.001 The essence is that each party generates a big random number, which it keeps 00:16:11.001 --> 00:16:14.001 secret, and then uses it to calculate a second number. 00:16:15.001 --> 00:16:18.001 The parties then exchange their respective results over the air. 00:16:20.000 --> 00:16:23.001 Somebody listening in can know both of these second numbers, but does 00:16:23.001 --> 00:16:25.001 not know the random number for either party. 00:16:27.000 --> 00:16:31.000 Each party combines the second number they received with the random number they 00:16:31.000 --> 00:16:33.000 kept secret to generate a third number. 00:16:34.000 --> 00:16:38.000 And the magic in the math is that the third number works out to be the same for 00:16:38.000 --> 00:16:41.000 both parties, and that third number is the shared secret. 00:16:42.000 --> 00:16:44.001 An eavesdropper cannot compute the third number. 00:16:46.000 --> 00:16:48.001 Neither party can control the contents of the shared secret, 00:16:49.000 --> 00:16:51.000 so it's not an encrypted message. 00:16:51.001 --> 00:16:53.000 No meaning has been obscured. 00:16:54.001 --> 00:16:59.000 Key agreement of this sort uses cryptographic methods, but it is not encryption, 00:16:59.001 --> 00:17:01.001 and not prohibited by the FCC rules. 00:17:03.000 --> 00:17:05.001 Okay, great. We're getting pretty close to a solution. 00:17:06.000 --> 00:17:08.000 We have a standard, well-trusted way to generate a shared 00:17:08.000 --> 00:17:10.000 secret, the Diffie-Hellman key agreement. 00:17:11.000 --> 00:17:16.000 And we have TOTP, a standard, well-trusted way to use that shared secret to 00:17:16.000 --> 00:17:18.000 generate one-time tokens for each uplink frame. 00:17:19.001 --> 00:17:21.001 We're still missing one essential ingredient. 00:17:23.000 --> 00:17:26.000 How do we know that the ground station is really who it says it is? 00:17:26.001 --> 00:17:29.001 In other words, how do we link a ground station to a 00:17:29.001 --> 00:17:31.000 particular real-world identity? 00:17:33.000 --> 00:17:37.000 Let's back up a minute. What do we mean by a real-world identity? 00:17:37.001 --> 00:17:43.000 This is really a policy question, so the answer depends on the desires of the 00:17:43.000 --> 00:17:46.000 satellite owner, and possibly on the choice of authentication 00:17:46.000 --> 00:17:47.001 mode in use at a given time. 00:17:49.000 --> 00:17:53.000 During a communications drill or emergency, for example, there may be a very 00:17:53.000 --> 00:17:57.001 specific list of stations that are authorized to use a satellite, and everybody 00:17:57.001 --> 00:18:00.000 else is blocked or restricted to certain kinds of use. 00:18:01.000 --> 00:18:05.001 In that case, what we mean by real-world identity is whatever sort of 00:18:05.001 --> 00:18:07.000 identification is used on that list. 00:18:08.000 --> 00:18:13.000 It might be a list of station call signs, but it could just as easily be a set of 00:18:13.000 --> 00:18:15.001 tactical identifiers that are specific to the served agency 00:18:15.001 --> 00:18:17.000 or to the specific drill. 00:18:18.000 --> 00:18:21.000 It's going to depend on what's needed for the situation at hand. 00:18:21.000 --> 00:18:25.001 For a more general amateur radio scenario, what we mean by real-world identity is 00:18:25.001 --> 00:18:27.001 almost certainly the amateur radio station call 00:18:27.001 --> 00:18:30.000 sign, held by a specific licensee. 00:18:31.000 --> 00:18:34.001 Call signs are handy. They're compact and globally unique. 00:18:35.001 --> 00:18:38.000 Everybody who can legally operate an amateur radio station 00:18:38.000 --> 00:18:39.001 has a station call sign. 00:18:40.001 --> 00:18:45.001 In case we need to impose accountability for misbehavior, the call sign is the 00:18:45.001 --> 00:18:49.000 best way to identify the individual involved, especially when a pattern of 00:18:49.000 --> 00:18:51.000 misbehavior calls for government involvement. 00:18:53.001 --> 00:18:58.001 In the United States, the FCC maintains a public database of call signs with the 00:18:58.001 --> 00:19:01.000 name of the licensee and a mailing address. 00:19:02.001 --> 00:19:07.001 The mailing address doesn't need to be the licensee's residence or the location 00:19:07.001 --> 00:19:12.000 of the station or any other particular address, but there is one requirement that 00:19:12.000 --> 00:19:17.001 does apply. The licensee must be able to receive mail at that address, and they 00:19:17.001 --> 00:19:19.000 can respond to correspondence from the FCC. 00:19:20.001 --> 00:19:24.000 The mailing address is the main thing that definitely ties 00:19:24.000 --> 00:19:25.001 the licensee to the license. 00:19:27.001 --> 00:19:32.000 Can you see where I'm going with this? Somebody has already dealt with these 00:19:32.000 --> 00:19:37.000 facts and solved the problem of authenticating amateur radio operators. 00:19:38.001 --> 00:19:43.001 Back around the year 2001, a group of amateurs was working on the problem of 00:19:43.001 --> 00:19:47.000 digitally authenticating amateur radio contact records. 00:19:48.000 --> 00:19:55.000 They called their project Trusted QSL, and they got the ARRL, the league, 00:19:55.001 --> 00:19:58.000 to adopt it for their Logbook of the World project. 00:19:59.001 --> 00:20:04.001 The Logbook of the World is a way to confirm contacts for awards without 00:20:04.001 --> 00:20:06.001 physically exchanging QSL cards. 00:20:07.000 --> 00:20:11.001 Each participating operator uploads the list of contacts they've made, their 00:20:11.001 --> 00:20:16.000 Logbook, and the system searches for matches between uploaded logs. 00:20:16.001 --> 00:20:19.001 If both ends of a contact have reported matching information in their uploaded 00:20:19.001 --> 00:20:22.001 logs, both stations get credit for the contact. 00:20:24.000 --> 00:20:27.001 Some people were worried that a system like this might somehow be less 00:20:27.001 --> 00:20:32.000 trustworthy than a traditional system of manually checking QSL cards. 00:20:33.000 --> 00:20:37.001 To reassure those people, the Trusted QSL designers chose to use a powerful 00:20:37.001 --> 00:20:42.000 cryptographic technique called the Digital Signature Standard to make it 00:20:42.000 --> 00:20:45.001 practically impossible for a Logbook upload to be faked by any third party. 00:20:47.000 --> 00:20:53.001 Each operator submitting a Logbook upload uses special software called TQSL to 00:20:53.001 --> 00:20:56.000 apply a digital signature to the log file. 00:20:57.000 --> 00:20:59.000 The signature can only be created by the holder of the call 00:20:59.000 --> 00:21:00.001 sign used to make the contacts. 00:21:02.000 --> 00:21:06.000 The validity of the signature can be checked cryptographically, and any 00:21:06.000 --> 00:21:09.000 alteration to any of the Logbook data will invalidate the signature. 00:21:11.001 --> 00:21:15.000 This trick depends on a method called Public Key Cryptography. 00:21:16.000 --> 00:21:19.001 The user has a key that is kept secret, referred to as the Private Key. 00:21:21.000 --> 00:21:24.000 From the Private Key, they can derive a second key called the Public Key. 00:21:25.000 --> 00:21:28.000 As you might guess from the name, the Public Key can be shared with everyone 00:21:28.000 --> 00:21:30.001 without compromising the Private Key. 00:21:32.000 --> 00:21:34.001 The Key Pair can be used in a variety of ways. 00:21:35.001 --> 00:21:40.000 For digital signatures, the Private Key is used to compute a number, called the 00:21:40.000 --> 00:21:43.001 Signature, based on the contents of a message to be signed. 00:21:45.000 --> 00:21:48.001 Since the Private Key is kept secret, only the holder of the Key Pair is 00:21:48.001 --> 00:21:50.000 capable of computing the signature. 00:21:51.000 --> 00:21:56.001 But through the magic of the math, anyone with a copy of the Public Key is able 00:21:56.001 --> 00:21:59.001 to determine whether the signature is valid, and was 00:21:59.001 --> 00:22:01.000 made with the corresponding Private Key. 00:22:02.000 --> 00:22:07.001 This gives us a way to tie a message, such as a Logbook upload, to a specific 00:22:07.001 --> 00:22:10.001 Private Key without knowing the Private Key. 00:22:11.001 --> 00:22:15.001 But it still doesn't give us a way to know the real-world identity of the sender. 00:22:15.001 --> 00:22:19.000 The standard solution to this problem uses a digital 00:22:19.000 --> 00:22:20.001 document called a Certificate. 00:22:21.000 --> 00:22:26.000 The Certificate contains a user's Public Key, and some kind of identification 00:22:26.000 --> 00:22:27.001 information about that user. 00:22:28.001 --> 00:22:31.000 In the case of the Logbook of the World, it contains the user's call sign. 00:22:32.001 --> 00:22:37.000 The Certificate itself is then digitally signed by some authority. 00:22:38.000 --> 00:22:42.000 The signing authority may append its own certificate, which is digitally signed 00:22:42.000 --> 00:22:45.000 in turn by some higher authority, and so on. 00:22:46.000 --> 00:22:51.000 At the top of a chain is a Certificate from a Root Authority, which signs itself. 00:22:52.000 --> 00:22:57.000 This chain of trust relies on the Root Certificate being well known to all. 00:22:58.000 --> 00:23:02.000 In order to validate any Certificate from anywhere in the chain of trust, you 00:23:02.000 --> 00:23:04.001 only have to have a trusted copy of the Root Certificate. 00:23:06.000 --> 00:23:09.000 Any other Certificate in the hierarchy can be validated by checking the 00:23:09.000 --> 00:23:11.000 signatures up the chain to the root. 00:23:12.000 --> 00:23:15.000 For the Logbook of the World, there is a single trusted Root Certificate 00:23:15.000 --> 00:23:17.001 built into the TQSL software. 00:23:18.001 --> 00:23:23.000 The League uses that Root Certificate to sign a working Certificate, which is in 00:23:23.000 --> 00:23:27.000 turn used to sign a Certificate for each station that uses Logbook of the World. 00:23:28.000 --> 00:23:31.001 For this scheme to work, we have to trust that each authority in the chain of 00:23:31.001 --> 00:23:36.001 trust has done a good job of checking that it only signs authentic Certificates. 00:23:37.001 --> 00:23:41.001 For Logbook of the World, we trust that the League has kept the private key 00:23:41.001 --> 00:23:46.000 associated with its Root Certificate secret, and that the League only uses that 00:23:46.000 --> 00:23:51.001 private key to sign valid working Certificates, which it will in turn only use to 00:23:51.001 --> 00:23:55.000 sign Certificates for authentic amateur radio licensees 00:23:55.000 --> 00:23:57.000 for their legitimate call signs. 00:23:58.001 --> 00:24:00.001 So how does the League manage to do that? 00:24:00.001 --> 00:24:06.001 When a US licensee applies for a Logbook of the World Certificate, the League 00:24:06.001 --> 00:24:11.001 looks up their call sign in the FCC database and mails a postcard to the user 00:24:11.001 --> 00:24:13.001 at their official registered address. 00:24:14.001 --> 00:24:18.000 The postcard contains login information for a new Logbook of the World account, 00:24:18.001 --> 00:24:20.000 and the user can download their new 00:24:20.000 --> 00:24:22.000 Certificate and private key from that account. 00:24:23.000 --> 00:24:27.001 A postcard may not seem like top flight security at first glance, but remember 00:24:27.001 --> 00:24:32.000 that being able to receive mail at a particular mailing address is essentially 00:24:32.000 --> 00:24:35.000 the only fact the FCC knows for sure about a licensee. 00:24:36.000 --> 00:24:40.000 That postcard gives Logbook of the World the same level of assured authentication 00:24:40.000 --> 00:24:43.000 as the FCC licensing process itself. 00:24:44.001 --> 00:24:49.000 For non-US licensees, the League uses a slightly different procedure. The user is 00:24:49.000 --> 00:24:51.001 required to send in a copy of their license and identification. 00:24:53.000 --> 00:24:59.001 The League validates the proof visually using some criteria before approving the 00:24:59.001 --> 00:25:03.001 user's request for a call sign certificate. I don't know what criteria they 00:25:03.001 --> 00:25:05.000 use. I don't think they've been published. 00:25:06.001 --> 00:25:11.001 So what does the Logbook of the World have to do with us? Well, we need something 00:25:11.001 --> 00:25:16.001 exactly like their certificates to tie satellite ground stations to real 00:25:16.001 --> 00:25:18.001 world identities. Call signs. 00:25:20.000 --> 00:25:25.000 In fact, we might as well just use the certificates issued by ARRL's Logbook of 00:25:25.000 --> 00:25:28.000 the World. There is no need to duplicate this mechanism 00:25:28.000 --> 00:25:30.000 or to build a separate chain of trust. 00:25:31.000 --> 00:25:37.001 As of this writing, Logbook of the World has 232,000 active certificates 00:25:37.001 --> 00:25:41.001 issued to 162,000 users worldwide. 00:25:43.000 --> 00:25:47.000 That's not every amateur radio operator in the world, not by a long shot, but it 00:25:47.000 --> 00:25:50.000 probably includes a good percentage of the most active operators. 00:25:51.000 --> 00:25:54.001 I'm guessing that most people who would be early adopters of a P4 XT satellite 00:25:54.001 --> 00:25:56.001 system already have a certificate. 00:25:58.001 --> 00:26:02.001 We're not stuck using just one source of certificates either. If the Logbook of 00:26:02.001 --> 00:26:06.001 the World certificates can't be used by everybody for any reason, it wouldn't be 00:26:06.001 --> 00:26:10.001 too big a deal to establish our own route certificate and issue call sign 00:26:10.001 --> 00:26:14.000 certificates of our own in the same way the League does for Logbook of the World. 00:26:14.001 --> 00:26:20.001 If some entity ever wants to use our P4 XT system design outside of the amateur 00:26:20.001 --> 00:26:24.000 radio services, they could easily establish their own chain of trust 00:26:24.000 --> 00:26:26.000 based on something other than call signs. 00:26:27.000 --> 00:26:30.000 The certificate system is more than flexible enough to 00:26:30.000 --> 00:26:31.001 accommodate any likely use case. 00:26:33.001 --> 00:26:37.001 So, with the addition of call sign certificates to our Key Agreement Scheme and 00:26:37.001 --> 00:26:41.001 TOTP Frame Authentication Tokens, we have all the necessary mechanisms 00:26:41.001 --> 00:26:43.000 to implement user authentication. 00:26:44.000 --> 00:26:45.001 Let's take a look at how this will work. 00:26:47.000 --> 00:26:50.000 A user buys or builds a P4 XT ground station. 00:26:51.000 --> 00:26:54.001 As part of the initial setup procedure, they configure the ground station with 00:26:54.001 --> 00:26:56.001 their call sign certificate from Logbook of the World 00:26:56.001 --> 00:26:58.001 or some other accepted source. 00:26:59.001 --> 00:27:03.000 They also configure the ground station with the identity they wish to use on the 00:27:03.000 --> 00:27:06.001 air, which is probably also their call sign, but could be anything. 00:27:07.001 --> 00:27:09.001 We call it the claimed identity. 00:27:11.000 --> 00:27:15.000 Some other configurations probably needed so the ground station knows the basic 00:27:15.000 --> 00:27:18.001 parameters of the satellite, such as its downlink frequency and symbol rate. 00:27:20.000 --> 00:27:23.001 The user then aims the ground station antenna at the satellite and begins to 00:27:23.001 --> 00:27:28.000 receive the multiplex DBB S2 or S2X downlink from the satellite. 00:27:29.000 --> 00:27:32.000 The user can now listen to traffic on the satellite to their heart's content. 00:27:32.000 --> 00:27:36.001 The downlink contains not just user traffic, but also traffic generated by the 00:27:36.001 --> 00:27:39.001 satellite itself, including telemetry from the satellite 00:27:39.001 --> 00:27:41.001 and other information of general interest. 00:27:42.001 --> 00:27:46.000 It also includes a stream of control messages, including a few 00:27:46.000 --> 00:27:47.001 that pertain to user authentication. 00:27:49.000 --> 00:27:51.001 One of these is the auth broadcast message. 00:27:52.001 --> 00:27:55.001 It contains various parameters that all users need to participate 00:27:55.001 --> 00:27:57.000 in the authentication protocol. 00:27:57.001 --> 00:28:01.000 It's transmitted once per second so that a ground station won't have to wait very 00:28:01.000 --> 00:28:03.000 long to receive it when first powering up. 00:28:04.000 --> 00:28:08.000 It contains the date and time to 40 millisecond resolution so that the ground 00:28:08.000 --> 00:28:12.000 station clock will be in sync with the satellite's clock, which is necessary for 00:28:12.000 --> 00:28:14.000 the TOTP tokens to match up correctly. 00:28:15.000 --> 00:28:19.000 It contains a unique identifier for the satellite, just in case we someday 00:28:19.000 --> 00:28:20.001 have many satellites in the sky. 00:28:21.001 --> 00:28:25.000 It contains the public parameters for the Diffie-Hellman key agreement protocol, 00:28:25.001 --> 00:28:29.001 and it contains two values that define how many frames can be transmitted 00:28:29.001 --> 00:28:31.000 with the same authentication token. 00:28:32.001 --> 00:28:34.001 The ground station records these values for later use. 00:28:35.001 --> 00:28:39.000 When the ground station wishes to transmit, it simply starts to transmit. 00:28:40.000 --> 00:28:44.001 If it has stored authentication information from a previous session, it can use 00:28:44.001 --> 00:28:47.000 the old information to fill in authentication tokens for each frame. 00:28:48.000 --> 00:28:52.000 If it does not have such information, default values are used to create a 00:28:52.000 --> 00:28:53.001 stream of tokens to use in the meantime. 00:28:55.000 --> 00:28:57.001 The satellite will receive these frames and evaluate 00:28:57.001 --> 00:28:59.000 the authentication tokens in them. 00:29:00.000 --> 00:29:02.000 What it does next will depend on the policy 00:29:02.000 --> 00:29:03.001 decision set by the satellite operator. 00:29:05.000 --> 00:29:08.001 We hope that under normal conditions, the satellite would go ahead and retransmit 00:29:08.001 --> 00:29:12.001 these frames on the downlink, even if the authentication tokens don't check out. 00:29:13.000 --> 00:29:17.001 This policy would be the friendliest to users, and also minimize the delay in 00:29:17.001 --> 00:29:19.001 case the user has emergency traffic to transmit. 00:29:21.001 --> 00:29:26.001 Then, or sometime later, according to satellite policy, the satellite may decide 00:29:26.001 --> 00:29:28.001 it wants to authenticate the user. 00:29:29.000 --> 00:29:33.001 This may occur because the user's tokens didn't check out, or just because it's 00:29:33.001 --> 00:29:37.001 been a while since the user was less authenticated, or for any other reason 00:29:37.001 --> 00:29:39.000 as dictated by satellite policy. 00:29:40.001 --> 00:29:45.001 The satellite initiates an authentication transaction by transmitting a directed 00:29:45.001 --> 00:29:49.001 auth challenge message, containing the claimed identity found in the 00:29:49.001 --> 00:29:51.000 transmission it wishes to authenticate. 00:29:52.001 --> 00:29:57.001 It also contains an identifier for this authentication transaction, a block of 00:29:57.001 --> 00:30:02.000 random bits to add security to the transaction, and the satellite's computed 00:30:02.000 --> 00:30:04.001 value for the Diffie-Hellman Key Agreement protocol. 00:30:05.001 --> 00:30:09.001 Notice that we're doing multiple things in parallel here. We're starting the 00:30:09.001 --> 00:30:13.000 certificate check, but we're also going ahead with the Key Agreement protocol. 00:30:15.000 --> 00:30:18.000 The ground station receives this message and matches up the claimed identity 00:30:18.000 --> 00:30:23.000 field to its own, and begins to process the authentication transaction. 00:30:24.000 --> 00:30:28.000 It formulates a virtual message that will be signed using the secret key 00:30:28.000 --> 00:30:30.000 associated with its call sign certificate. 00:30:30.001 --> 00:30:34.001 Notice this virtual message is never actually transmitted by either station. 00:30:35.001 --> 00:30:40.000 The message echoes back the satellite identifier from the auth broadcast, and the 00:30:40.000 --> 00:30:44.000 claimed identity that was challenged in the directed auth challenge, along with 00:30:44.000 --> 00:30:45.001 the challenge bits from the message. 00:30:47.000 --> 00:30:52.000 The ground station supplies its actual identity, its call sign, which must match 00:30:52.000 --> 00:30:54.000 the identity embedded in its certificate. 00:30:55.000 --> 00:31:01.000 The ground station also supplies its own computed value for Key Agreement, and 00:31:01.000 --> 00:31:05.000 the number of times it intends to repeat authentication tokens, within the limits 00:31:05.000 --> 00:31:06.001 specified in the auth broadcast. 00:31:07.001 --> 00:31:11.000 The ground station then computes a signature for this virtual message. 00:31:12.000 --> 00:31:15.000 Now the ground station is ready to reply to the challenge 00:31:15.000 --> 00:31:16.001 with an auth response message. 00:31:16.001 --> 00:31:21.000 The auth response contains all the information the satellite doesn't already 00:31:21.000 --> 00:31:24.001 have, but needs to be able to reconstruct the virtual message. 00:31:25.001 --> 00:31:30.000 The challenged claimed identity, the actual identity, the challenge identifier, 00:31:31.001 --> 00:31:35.001 the ground station's computed value for Key Agreement, and the ground station's 00:31:35.001 --> 00:31:37.000 intended number of repeats for tokens. 00:31:38.001 --> 00:31:44.000 The ground station appends the signature it computed for the virtual message, and 00:31:44.000 --> 00:31:46.000 a copy of the ground station's certificate. 00:31:47.000 --> 00:31:51.001 The satellite is able to validate the certificate based on information contained 00:31:51.001 --> 00:31:55.001 in the certificate, tracing the chain of trust back to one of the root 00:31:55.001 --> 00:31:57.001 certificates that the satellite knows about. 00:31:58.001 --> 00:32:02.000 The certificate also gives the satellite the information it needs to check the 00:32:02.000 --> 00:32:04.000 signature computed on the virtual message. 00:32:05.000 --> 00:32:08.001 If everything checks out, the satellite can trust that everything 00:32:08.001 --> 00:32:10.000 is as it appears to be. 00:32:11.001 --> 00:32:16.001 The satellite then transmits an auth-ac message. This message contains both the 00:32:16.001 --> 00:32:18.001 claimed identity and the actual identity. 00:32:20.000 --> 00:32:24.001 Notice that means the ground station cannot be truly anonymous, even to other 00:32:24.001 --> 00:32:28.000 users, even if its claimed identity doesn't have any obvious 00:32:28.000 --> 00:32:29.001 relationship to its actual identity. 00:32:30.001 --> 00:32:34.001 Since any ground station can receive the auth-ac message and associate the 00:32:34.001 --> 00:32:36.000 actual identity with the claimed identity. 00:32:38.000 --> 00:32:40.001 The auth-ac message also informs the ground station of the 00:32:40.001 --> 00:32:42.001 result of its authentication transaction. 00:32:44.000 --> 00:32:49.000 If everything was accepted, the response is, welcome, and the ground station may 00:32:49.000 --> 00:32:51.001 continue transmitting. In other cases, the response 00:32:51.001 --> 00:32:53.000 might be one of these other values. 00:32:55.000 --> 00:32:58.001 If the ground station is authorized to continue transmitting, then the switchover 00:32:58.001 --> 00:33:01.000 time from the auth-ac comes into play. 00:33:01.000 --> 00:33:06.000 This identifies the specific frame where the ground station is supposed to switch 00:33:06.000 --> 00:33:10.001 over from using its old or default authentication tokens to using newly computed 00:33:10.001 --> 00:33:14.000 authentication tokens based on the shared secret agreed upon using 00:33:14.000 --> 00:33:15.001 the Diffie-Hellman Key Agreement protocol. 00:33:16.001 --> 00:33:20.001 So there's no ambiguity. The ground station and the satellite both know exactly 00:33:20.001 --> 00:33:23.000 what's supposed to go in the authentication token of every frame. 00:33:23.000 --> 00:33:28.000 If the tokens don't match, the satellite can treat that as evidence that 00:33:28.000 --> 00:33:29.001 the ground station is not authentic. 00:33:31.000 --> 00:33:35.000 What it does then depends on policy, but it might well stop re-transmitting 00:33:35.000 --> 00:33:38.000 traffic from that ground station and log an authentication error. 00:33:39.001 --> 00:33:42.000 It's worth mentioning here that the satellite never re-transmits the 00:33:42.000 --> 00:33:46.000 authentication tokens. They're of no use to other ground stations, and re 00:33:46.000 --> 00:33:49.001 -transmitting them might cause a sneaky side-channel for encrypted communications. 00:33:51.000 --> 00:33:55.001 Once the auth-ac has been received and the switchover time has arrived, the 00:33:55.001 --> 00:33:57.000 ground station generates authentication tokens. 00:33:58.000 --> 00:34:01.000 The date, time, and the shared secret from the Diffie-Hellman Key Agreement 00:34:01.000 --> 00:34:04.000 protocol go into a SHA-1 hash function. 00:34:04.001 --> 00:34:09.001 The hash function computes a 160-bit number. An additional calculation is used 00:34:09.001 --> 00:34:11.000 to extract a smaller number. 00:34:12.001 --> 00:34:17.001 In vanilla TOTP, this is the six-digit passcode the user would read off the 00:34:17.001 --> 00:34:20.001 hardware token and type in to authenticate a login. 00:34:21.000 --> 00:34:25.001 For our application, we use this number as the authentication token for a frame 00:34:25.001 --> 00:34:27.001 or a short sequence of consecutive frames. 00:34:29.001 --> 00:34:33.001 It would probably be possible to customize this calculation for our purposes and 00:34:33.001 --> 00:34:35.001 come up with something more efficient than running the entire 00:34:35.001 --> 00:34:37.000 hash function for every frame. 00:34:38.000 --> 00:34:43.001 However, when mucking about with cryptographic protocols, it's notoriously easy 00:34:43.001 --> 00:34:47.000 to make a subtle little mistake and destroy the security of the protocol. 00:34:48.001 --> 00:34:52.001 Since we're not expert cryptographers, it's safer to just use an existing well 00:34:52.001 --> 00:34:56.000 -accepted protocol without modifications, to the extent possible. 00:34:56.001 --> 00:35:00.001 We presented this poster of our authentication scheme at the hacker convention, 00:35:01.000 --> 00:35:05.000 DEF CON 30, a few weeks ago, and asked the hackers for advice. 00:35:05.001 --> 00:35:11.000 We received some excellent feedback from Kate Gray, W9KAT, pointing out a 00:35:11.000 --> 00:35:14.001 possible security blunder we had made in modifying TOTP. 00:35:15.001 --> 00:35:20.000 Using TOTP unmodified is definitely safer, and that's the current plan. 00:35:22.000 --> 00:35:26.000 Kate also pointed out that with a minor change, we could have the authentication 00:35:26.000 --> 00:35:30.000 token protect the contents of the frame payload from modification. 00:35:31.000 --> 00:35:34.001 The token would authenticate not just the sender, but the message itself. 00:35:35.001 --> 00:35:37.000 We're still evaluating that suggestion. 00:35:39.001 --> 00:35:43.000 I've shown you a method by which the origin of every uplink transmission can be 00:35:43.000 --> 00:35:44.001 identified with high assurance. 00:35:45.001 --> 00:35:49.000 With this protocol in place, as part of the overall system protocol needed to 00:35:49.000 --> 00:35:54.000 access and use the P4 XT satellite, the satellite operator will have the ability 00:35:54.000 --> 00:35:59.000 to control access to the system and impose accountability on misbehaving users. 00:36:00.001 --> 00:36:04.000 Except for the need to provide a call sign certificate to the ground station 00:36:04.000 --> 00:36:07.001 controller, this imposes no burden on the individual user of a ground 00:36:07.001 --> 00:36:09.001 station. Everything is automatic. 00:36:10.001 --> 00:36:15.000 The burden on a satellite operator is also light, since the satellite itself can 00:36:15.000 --> 00:36:17.001 be programmed to implement the designated policy. 00:36:19.001 --> 00:36:24.000 A prototype implementation of the actual cryptographic calculations used in this 00:36:24.000 --> 00:36:26.001 design has been written in Python in a Jupyter notebook 00:36:26.001 --> 00:36:28.001 and benchmarked on a Raspberry Pi. 00:36:29.001 --> 00:36:33.000 This shows that the computations are not too burdensome for an embedded 00:36:33.000 --> 00:36:36.000 processor, such as might be used in a typical satellite design. 00:36:37.000 --> 00:36:40.001 That Jupyter notebook and other documents describing this authentication protocol 00:36:40.001 --> 00:36:44.000 can be found in our GitHub repository at this URL. 00:36:46.000 --> 00:36:50.001 This is still an early version of the design. Only the authentication protocol 00:36:50.001 --> 00:36:52.001 part has been fleshed out to even this level of detail. 00:36:52.001 --> 00:36:57.001 So there's still time for you to get involved and help out. 00:36:58.001 --> 00:37:03.000 Your comments and suggestions are sincerely welcomed. We do all our work out in 00:37:03.000 --> 00:37:08.001 the open, publishing as we go. Not just open source, but open process, too. 00:37:09.001 --> 00:37:13.001 If you're interested in helping out, please visit openresearch 00:37:13.001 --> 00:37:15.001 .institute and click on Getting Started. 00:37:16.001 --> 00:37:20.000 You don't have to be an expert, but you might accidentally become one. 00:37:20.000 --> 00:37:23.001 Thanks for listening. I'll try to answer any 00:37:23.001 --> 00:37:25.000 questions you may have in the time remaining. 00:37:41.000 --> 00:37:46.000 Hello. Please type any questions you may have into the chat 00:37:46.000 --> 00:37:48.000 and I'll do what I can to answer them. 00:37:50.000 --> 00:38:16.000 Thank you. 00:38:20.000 --> 00:38:21.000 No questions. 00:39:08.000 --> 00:39:11.000 I'm afraid this is not going to be a very lively Q&A session. 00:39:20.000 --> 00:39:50.000 Thank you. 00:40:12.000 --> 00:40:18.000 I see a question from Gary into AMC. Has this approach been discussed with AMSAT? 00:40:18.000 --> 00:40:21.001 Not in any kind of detail, no. 00:40:36.001 --> 00:40:40.000 And thank you, Gary, for proving that the comment system actually is working. 00:40:42.000 --> 00:40:45.000 Anybody else with questions, please type them in. 00:40:47.000 --> 00:40:52.001 Comments are welcome, too. 00:41:08.000 --> 00:41:12.000 Jeffrey asked, can you describe the P4 XT transponder a bit more 00:41:12.000 --> 00:41:13.001 as to what it is and what it does? 00:41:14.000 --> 00:41:15.000 [...] 00:41:18.001 --> 00:41:22.000 The P4 XT transponder is a fully digital transponder, so 00:41:22.000 --> 00:41:24.000 uplinks and downlinks are both digital. 00:41:25.000 --> 00:41:30.001 The downlink is based on a very standard and very state-of-the-art 00:41:30.001 --> 00:41:34.001 modulation and protocol called 00:41:34.001 --> 00:41:38.001 DBBS2S2X, an extended version of that. 00:41:38.001 --> 00:41:44.001 This is one big pipe coming down from the satellite with every user's 00:41:44.001 --> 00:41:49.001 traffic and anything else that the satellite may wish to transmit all multiplex 00:41:49.001 --> 00:41:55.000 into one transmission, so every user can conceptually receive everything. 00:41:56.000 --> 00:41:58.001 And then on the uplink, individual channels are allocated. 00:41:59.000 --> 00:42:05.001 Sort of the baseline communication would be voice, so a channel 00:42:05.001 --> 00:42:12.000 wide enough to carry a high-quality digital voice, see my next talk, will 00:42:12.000 --> 00:42:14.001 be transmitted on the uplink. 00:42:14.001 --> 00:42:21.000 And then the satellite itself will do the multiplexing automatically, receiving 00:42:21.000 --> 00:42:26.000 whatever comes up on the uplinks and authenticating them, as described here in 00:42:26.000 --> 00:42:29.001 this talk, and prioritizing them if necessary 00:42:29.001 --> 00:42:31.001 and transmitting them on the downlink. 00:42:32.001 --> 00:42:34.001 Voice is not the only thing that can be used for, of course, it can be used for 00:42:34.001 --> 00:42:40.001 data or higher speed communications up to some limit, depending on how large 00:42:40.001 --> 00:42:42.001 the user's ground station is. 00:42:43.000 --> 00:42:49.001 That is the basic idea. It's intended to be used in a geostationary orbit. You 00:42:49.001 --> 00:42:54.000 may have to compromise and use it in a high orbit, either an elliptical one or a 00:42:54.000 --> 00:42:58.001 graveyard orbit near geostationary, but not exactly geostationary. 00:42:59.001 --> 00:43:05.000 And we also intend for it to be usable on the ground. You could put a ground sat 00:43:05.000 --> 00:43:10.000 or a satellite simulator sort of device on a tower, on a tall building, or a 00:43:10.000 --> 00:43:15.000 mount and top if you're so blessed in your area, and do the same sorts of thing. 00:43:17.001 --> 00:43:22.000 I think that pretty much covers the basics of it. Your next question would 00:43:22.000 --> 00:43:27.001 probably be when, we don't know, what launch, we don't know. 00:43:27.001 --> 00:43:32.001 Who's going to pay for it? That's also a problem. Like a lot of ambitious 00:43:32.001 --> 00:43:39.000 projects, this is going to have to rely on some luck and some 00:43:39.000 --> 00:43:43.001 wrangling, and we have not yet gotten there. 00:43:54.001 --> 00:43:59.001 Gary asked a follow-up question. Do you intend to discuss it with them, AMSAT? If 00:43:59.001 --> 00:44:02.001 AMSAT is involved in the project at some point, 00:44:03.001 --> 00:44:05.001 we will, of course, discuss it with them. 00:44:06.000 --> 00:44:13.000 AMSAT has not shown a lot of interest in our project, except 00:44:13.000 --> 00:44:18.000 negatively. So for the time being, we've not been discussing this with AMSAT. 00:44:27.001 --> 00:44:30.000 That's all the questions I've seen so far, so type in more. 00:44:32.000 --> 00:44:32.001 Thank you, Jeffrey. 00:44:40.000 --> 00:44:46.000 You can join mailing lists, Slack channel, watch the GitHub. 00:44:47.001 --> 00:44:50.000 There are many different ways to keep track of what we're doing. We're completely 00:44:50.000 --> 00:44:52.000 open and transparent about everything we're doing. 00:44:53.001 --> 00:44:54.001 That's a goal anyway. 00:45:11.000 --> 00:45:13.001 That doesn't need to be responded to here. 00:45:38.001 --> 00:45:41.001 Thank you, Gary. 00:46:08.001 --> 00:46:15.000 I'm not seeing any new comments coming in. While we've got a Slack 00:46:15.000 --> 00:46:19.001 minute here, I will thank Eric KF0-AMA, who is serving as host for this 00:46:19.001 --> 00:46:23.000 presentation. Thanks for your help. 00:46:58.000 --> 00:47:02.000 Well, what do you think, Eric? Should we call it? 00:47:08.001 --> 00:47:11.001 You're not on screen until I can't hear you. 00:47:17.000 --> 00:47:18.001 Yeah, we can go ahead and call it. 00:47:20.000 --> 00:47:23.000 Okay, well, thank you all for your attention. If you have any questions that you 00:47:23.000 --> 00:47:28.000 didn't get into the chat for whatever reason, get ahold of me. You 00:47:28.000 --> 00:47:30.000 can find me at Open Research at that [...] 00:47:32.000 --> 00:47:36.000 Lots of other places as well. So thanks for your attention and 00:47:36.000 --> 00:47:38.000 enjoy the rest of HamExpo.